Method of delivering direct proof private keys to devices using an on-line service

ABSTRACT

Delivering a Direct Proof private key to a device installed in a client computer system in the field may be accomplished in a secure manner without requiring significant non-volatile storage in the device. A unique pseudo-random value is generated and stored in the device at manufacturing time. The pseudo-random value is used to generate a symmetric key for encrypting a data structure holding a Direct Proof private key and a private key digest associated with the device. The resulting encrypted data structure is stored on a protected on-line server accessible by the client computer system.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.10/892,256, filed on Jul. 14, 2004 now U.S. Pat. No. 7,697,691.

BACKGROUND

1. Field

The present invention relates generally to computer security and, morespecifically, to securely distributing cryptographic keys to devices inprocessing systems.

2. Description

Some processing system architectures supporting content protectionand/or computer security features require that specially-protected or“trusted” software modules be able to create an authenticated encryptedcommunications session with specific protected or “trusted” hardwaredevices in the processing system (such as graphics controller cards, forexample). One commonly used method for both identifying the device andsimultaneously establishing the encrypted communications session is touse a one-side authenticated Diffie-Hellman (DH) key exchange process.In this process, the device is assigned a unique public/private Rivest,Shamir and Adelman (RSA) algorithm key pair or a unique Elliptic CurveCryptography (ECC) key pair. However, because this authenticationprocess uses RSA or ECC keys, the device then has a unique and provableidentity, which can raise privacy concerns. In the worst case, theseconcerns may result in a lack of support from original equipmentmanufacturers (OEMs) for building trustable devices providing this kindof security.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will becomeapparent from the following detailed description of the presentinvention in which:

FIG. 1 illustrates a system featuring a platform implemented with aTrusted Platform Module (TPM) that operates in accordance with oneembodiment of the invention;

FIG. 2 illustrates a first embodiment of the platform including the TPMof FIG. 1.

FIG. 3 illustrates a second embodiment of the platform including the TPMof FIG. 1.

FIG. 4 illustrates an exemplary embodiment of a computer systemimplemented with the TPM of FIG. 2.

FIG. 5 is a diagram of a system for distributing Direct Proof keys todevices using an on-line service according to an embodiment of thepresent invention;

FIG. 6 is a flow diagram illustrating stages of a method of distributingDirect Proof keys using an on-line service according to an embodiment ofthe present invention;

FIG. 7 is a flow diagram illustrating protected server set-up processingaccording to an embodiment of the present invention;

FIG. 8 is a flow diagram illustrating device manufacturer set-upprocessing according to an embodiment of the present invention;

FIG. 9 is a flow diagram illustrating device manufacturer productionprocessing according to an embodiment of the present invention;

FIGS. 10-12 are flow diagrams of client computer system set-upprocessing according to an embodiment of the present invention; and

FIG. 13 is a flow diagram of client computer system processing accordingto an embodiment of the present invention.

DETAILED DESCRIPTION

Using the Direct Proof-based Diffie-Hellman key exchange protocol topermit protected/trusted devices to authenticate themselves and toestablish an encrypted communication session with trusted softwaremodules avoids creating any unique identity information in theprocessing system, and thereby avoids introducing privacy concerns.However, directly embedding a Direct Proof private key in a device on amanufacturing line requires more protected non-volatile storage on thedevice than other approaches, increasing device costs. An embodiment ofthe present invention is a method to allow the Direct Proof (DP) privatekey (e.g., used for signing) to be delivered in a secure manner to thedevice using an on-line service, and subsequently installed in thedevice by the device itself. The method presented in this invention isdesigned so that the device does not need to reveal identity informationfor the installation process. In one embodiment, the reduction in devicestorage required to support this capability may be from approximately300 to 700 bytes down to approximately 40 bytes. This reduction in theamount of non-volatile storage required to implement Direct Proof-basedDiffie-Hellman key exchange for devices may result in broader adoptionof this technique.

In embodiments of the present invention, DP private signing keys are notdistributed in or with a device. Instead, the device supports a protocolby which the device in the field may safely retrieve its private keyfrom an on-line protected server provided by a manufacturer or vendor,or a delegate. This protocol creates a trusted channel between thedevice and the server, and does not require trust in any interveningsoftware, including software on a local processing system.

Reference in the specification to “one embodiment” or “an embodiment” ofthe present invention means that a particular feature, structure orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the present invention. Thus, theappearances of the phrase “in one embodiment” appearing in variousplaces throughout the specification are not necessarily all referring tothe same embodiment.

In the following description, certain terminology is used to describecertain features of one or more embodiments of the invention. Forinstance, “platform” is defined as any type of communication device thatis adapted to transmit and receive information. Examples of variousplatforms include, but are not limited or restricted to computersystems, personal digital assistants, cellular telephones, set-topboxes, facsimile machines, printers, modems, routers, or the like. A“communication link” is broadly defined as one or moreinformation-carrying mediums adapted to a platform. Examples of varioustypes of communication links include, but are not limited or restrictedto electrical wire(s), optical fiber(s), cable(s), bus trace(s), orwireless signaling technology.

A “challenger” refers to any entity (e.g., person, platform, system,software, and/or device) that requests some verification of authenticityor authority from another entity. Normally, this is performed prior todisclosing or providing the requested information. A “responder” refersto any entity that has been requested to provide some proof of itsauthority, validity, and/or identity. A “device manufacturer,” which maybe used interchangeably with “certifying manufacturer,” refers to anyentity that manufactures or configures a platform or device.

As used herein, to “prove” or “convince” a challenger that a responderhas possession or knowledge of some cryptographic information (e.g.,digital signature, a secret such as a key, etc.) means that, based onthe information and proof disclosed to the challenger, there is a highprobability that the responder has the cryptographic information. Toprove this to a challenger without “revealing” or “disclosing” thecryptographic information to the challenger means that, based on theinformation disclosed to the challenger, it would be computationallyinfeasible for the challenger to determine the cryptographicinformation.

Such proofs are hereinafter referred to as direct proofs. The term“direct proof” refers to zero-knowledge proofs, as these types of proofsare commonly known in the field. In particular, a specific Direct Proofprotocol as referenced herein is the subject of co-pending patentapplication Ser. No. 10/306,336, filed on Nov. 27, 2002, entitled“System and Method for Establishing Trust Without Revealing Identity,”assigned to the owner of the present application. Direct Proof defines aprotocol in which an issuer defines a family of many members that sharecommon characteristics as defined by the issuer. The issuer generates aFamily public and private key pair (Fpub and Fpri) that represents thefamily as a whole. Using Fpri, the issuer can also generate a uniqueDirect Proof private signing key (DPpri) for each individual member inthe family. Any message signed by an individual DPpri can be verifiedusing the family public key Fpub. However, such verification onlyidentifies that the signer is a member of the family; no uniquelyidentifying information about the individual member is exposed. In oneembodiment, the issuer may be a device manufacturer or delegate. Thatis, the issuer may be an entity with the ability to define deviceFamilies based on shared characteristics, generate the Familypublic/private key pair, and to create and inject DP private keys intodevices. The issuer may also generate certificates for the Family publickey that identify the source of the key and the characteristics of thedevice family.

Referring now to FIG. 1, an embodiment of a system featuring a platformimplemented with a trusted hardware device (referred to as “TrustedPlatform Module” or “TPM”) that operates in accordance with oneembodiment of the invention is shown. A first platform 102 (Challenger)transmits a request 106 that a second platform 104 (Responder) providesinformation about itself. In response to request 106, second platform104 provides the requested information 108.

Additionally, for heightened security, first platform 102 may need toverify that requested information 108 came from a device manufactured byeither a selected device manufacturer or a selected group of devicemanufacturers (hereinafter referred to as “device manufacturer(s) 110”).For instance, for one embodiment of the invention, first platform 102challenges second platform 104 to show that it has cryptographicinformation (e.g., a signature) generated by device manufacturer(s) 110.The challenge may be either incorporated into request 106 (as shown) ora separate transmission. Second platform 104 replies to the challenge byproviding information, in the form of a reply, to convince firstplatform 102 that second platform 104 has cryptographic informationgenerated by device manufacturer(s) 110, without revealing thecryptographic information. The reply may be either part of the requestedinformation 108 (as shown) or a separate transmission.

In one embodiment of the invention, second platform 104 comprises aTrusted Platform Module (TPM) 115. TPM 115 is a cryptographic devicethat is manufactured by device manufacturer(s) 110. In one embodiment ofthe invention, TPM 115 comprises a processor with a small amount ofon-chip memory encapsulated within a package. TPM 115 is configured toprovide information to first platform 102 that would enable it todetermine that a reply is transmitted from a valid TPM. The informationused is content that would not make it likely that the TPM's or secondplatform's identity can be determined.

FIG. 2 illustrates a first embodiment of second platform 104 with TPM115. For this embodiment of the invention, second platform 104 comprisesa processor 202 coupled to TPM 115. In general, processor 202 is adevice that processes information. For instance, in one embodiment ofthe invention, processor 202 may be implemented as a microprocessor,digital signal processor, micro-controller or even a state machine.Alternatively, in another embodiment of the invention, processor 202 maybe implemented as programmable or hard-coded logic, such as FieldProgrammable Gate Arrays (FPGAs), transistor-transistor logic (TTL)logic, or even an Application Specific Integrated Circuit (ASIC).

Herein, second platform 104 further comprises a storage unit 206 topermit storage of cryptographic information such as one or more of thefollowing: keys, hash values, signatures, certificates, etc. A hashvalue of “X” may be represented as “Hash(X)”. It is contemplated thatsuch information may be stored within internal memory 220 of TPM 115 inlieu of storage unit 206 as shown in FIG. 3. The cryptographicinformation may be encrypted, especially if stored outside TPM 115.

FIG. 4 illustrates an embodiment of a platform including a computersystem 300 implemented with TPM 115 of FIG. 2. Computer system 300comprises a bus 302 and a processor 310 coupled to bus 302. Computersystem 300 further comprises a main memory unit 304 and a static memoryunit 306.

Herein, main memory unit 304 is volatile semiconductor memory forstoring information and instructions executed by processor 310. Mainmemory 304 also may be used for storing temporary variables or otherintermediate information during execution of instructions by processor310. Static memory unit 306 is non-volatile semiconductor memory forstoring information and instructions for processor 310 on a morepermanent nature. Examples of static memory 306 include, but are notlimited or restricted to read only memory (ROM). Both main memory unit304 and static memory unit 306 are coupled to bus 302.

In one embodiment of the invention, computer system 300 furthercomprises a data storage device 308 such as a magnetic disk or opticaldisc and its corresponding drive may also be coupled to computer system300 for storing information and instructions.

Computer system 300 can also be coupled via bus 302 to a graphicscontroller device 314, which controls a display (not shown) such as acathode ray tube (CRT), Liquid Crystal Display (LCD) or any flat paneldisplay, for displaying information to an end user. In one embodiment,it may be desired for the graphics controller to be able to establish anauthenticated encrypted communications session with a software modulebeing executed by the processor.

Typically, an alphanumeric input device 316 (e.g., keyboard, keypad,etc.) may be coupled to bus 302 for communicating information and/orcommand selections to processor 310. Another type of user input deviceis cursor control unit 318, such as a mouse, a trackball, touch pad,stylus, or cursor direction keys for communicating direction informationand command selections to processor 310 and for controlling cursormovement on display 314.

A communication interface unit 320 is also coupled to bus 302. Examplesof interface unit 320 include a modem, a network interface card, orother well-known interfaces used for coupling to a communication linkforming part of a local or wide area network. In this manner, computersystem 300 may be coupled to a number of clients and/or servers via aconventional network infrastructure, such as a company's Intranet and/orthe Internet, for example. In one embodiment, the computer system may becoupled on-line over a network to a protected server.

It is appreciated that a lesser or more equipped computer system thandescribed above may be desirable for certain implementations. Therefore,the configuration of computer system 300 will vary from implementationto implementation depending upon numerous factors, such as priceconstraints, performance requirements, technological improvements,and/or other circumstances.

In at least one embodiment, computer system 300 may support the use ofspecially-protected “trusted” software modules (e.g., tamper-resistantsoftware, or systems having the ability to run protected programs)stored in main memory 304 and/or mass storage device 308 and beingexecuted by processor 310 to perform specific activities, even in thepresence of other hostile software in the system. Some of these trustedsoftware modules require equivalently “trustable” protected access notjust to other platforms, but to one or more peripheral devices withinthe same platform, such as graphics controller 314. In general, suchaccess requires that the trusted software module be able to identify thedevice's capabilities and/or specific identity, and then establish anencrypted session with the device to permit the exchange of data thatcannot be snooped or spoofed by other software in the system.

One prior art method of both identifying the device and simultaneouslyestablishing the encrypted session is to use a one-side authenticatedDiffie-Hellman (DH) key exchange process. In this process, the device isassigned a unique public/private RSA or ECC key pair. The device holdsand protects the private key, while the public key, along withauthenticating certificates, may be released to the software module.During the DH key exchange process, the device signs a message using itsprivate key, which the software module can verify using thecorresponding public key. This permits the software module toauthenticate that the message did in fact come from the device ofinterest.

However, because this authentication process uses RSA or ECC keys, thedevice has a unique and provable identity. Any software module that canget the device to sign a message with its private key can prove thatthis specific unique device is present in the computer system. Giventhat devices rarely migrate between processing systems, this alsorepresents a provable unique computer system identity. Furthermore, thedevice's public key itself represents a constant unique value;effectively a permanent “cookie.” In some cases, these characteristicsmay be construed as a significant privacy problem.

One alternative approach is described in co-pending patent applicationSer. No. 10/999,576, filed on Nov. 30, 2004, entitled “An Apparatus andMethod for Establishing an Authenticated Encrypted Session with a DeviceWithout Exposing Privacy-Sensitive Information,” assigned to the ownerof the present application. In that approach, the use of RSA or ECC keysin the one-sided authenticated Diffie-Hellman process is replaced withDirect Proof keys. A device using this approach may be authenticated asbelonging to a specific Family of devices, which may include assurancesabout the behavior or trustworthiness of the device. The approach doesnot expose any uniquely identifying information that could be used toestablish a unique identity representing the processing system.

Although this approach works well, it requires additional storage in thedevice to hold the Direct Proof private key, which may be larger than aRSA or ECC key. To alleviate the burdens of this additional storagerequirement, embodiments of the present invention define a system andprocess for ensuring that the device has the Direct Proof private keywhen it needs the key, without requiring substantial additional storagein the device.

In at least one embodiment of the present invention, a devicemanufacturer stores a 128-bit pseudorandom number into a device in themanufacturing line, and a much larger Direct Proof private key (DPpri)may be encrypted and delivered to the device in the field using anon-line service operated by a protected server. Other embodiments maystore a number into the device that is longer or shorter than 128 bits.This process ensures that only a specified device can decrypt and useits assigned DPpri key. FIG. 5 is a diagram of a system 500 fordistributing Direct Proof keys according to an embodiment of the presentinvention. There are four entities in this system, a devicemanufacturing protected system 502, a device manufacturing productionsystem 503, a client computer system 504, and a protected server 522.The device manufacturing protected system comprises a processing systemused in the set-up process prior to manufacturing of a device 506. Themanufacturing protected system 502 may be operated by a devicemanufacturer such that the protected system is protected from attackfrom hackers outside the device manufacturing site (e.g., it is a closedsystem). Manufacturing production system 503 may be used in themanufacturing of the devices. In one embodiment, the protected systemand the production system may be the same system. Device 506 comprisesany hardware device for inclusion in the client computer system (e.g., amemory controller, a peripheral device such as a graphics controller, anI/O device, etc.). In embodiments of the present invention, the devicecomprises a pseudorandom value RAND 508, and a key service public keyhash value 509, stored in non-volatile storage of the device.

The manufacturing protected system includes a protected database 510 anda generation function 512. The protected database comprises a datastructure for storing multiple pseudorandom values (at least as many asone per device to be manufactured) generated by generation function 512in a manner as described below. The generation function comprises logic(either implemented in software or hardware) to generate a datastructure called a keyblob 514 herein. Keyblob 514 comprises at leastthree data items. A unique Direct Proof private key (DPpri) comprises acryptographic key which may be used by a device for signing. DP privatedigest 518 (DPpri Digest) comprises a message digest of DPpri 516according to any well-known method of generating a secure messagedigest, such as SHA-1. Some embodiments may include a pseudorandominitialization vector (IV) 515 comprising a bit stream as part of thekeyblob for compatibility purposes. If a stream cipher is used for theencryption, then the IV is used in a well known method for using an IVin a stream cipher. If a block cipher is used for the encryption, thenthe IV will be used as part of the message to be encrypted, thus makingeach instance of the encryption be different. The manufacturingprotected system also includes a key service public key 507 used for anon-line protocol as described in further detail below.

In embodiments of the present invention, the manufacturing protectedsystem generates one or more keyblobs (as described in detail below) andstores the keyblobs in a keyblob database 520 on a protected server 522.In one embodiment, there may be many keyblobs in the keyblob database.The protected server may be operated by the device manufacturer, devicedistributor, or other affiliated entity. The protected server may becommunicatively coupled to a client computer system 504 using a network,such as the Internet for example. The protected server also includes akey service private key 511 for use in the on-line protocol between theprotected server and the device.

A client computer system 504 desiring to use a Direct Proof protocol forauthentication and key exchange of a communications session with device506 included within system 504 may read a selected keyblob 514 out ofthe keyblob database 520 on the protected server using a key servicepublic/private key pair and the on-line protocol described in furtherdetail below. The keyblob data may be used by the device to generate alocalized keyblob 524 (as described below) for use in implementing theDirect Proof protocol. Device driver software 526 is executed by theclient computer system to initialize and control device 506.

In embodiments of the present invention, there may be five distinctstages of operation. FIG. 6 is a flow diagram 600 illustrating stages ofa method of distributing Direct Proof keys according to an embodiment ofthe present invention. According to embodiments of the presentinvention, certain actions may be performed at each stage. At a site ofa device manufacturer, there are at least three stages: protected serverset-up stage 601, device manufacturer set-up stage 602, and devicemanufacturer production stage 604. The protected server set-up stage isdescribed herein with reference to FIG. 7. The device manufacturerset-up stage is described herein with reference to FIG. 8. The devicemanufacturer production stage is described herein with reference to FIG.9. At a consumer site having the client computer system, there are atleast two stages: client computer system set-up stage 606, and clientcomputer system use stage 608. The client computer system set-up stageis described herein with reference to FIGS. 10-12. The client computersystem use stage is described herein with reference to FIG. 13.

FIG. 7 is a flow diagram 700 illustrating protected server set-up stageprocessing according to an embodiment of the present invention. Thisprocessing may be performed by a device manufacturer prior to productionof devices. At block 702, a device manufacturer establishes a protectedserver 522 to support key retrieval requests. In one embodiment, theprotected server is communicatively coupled to the Internet in awell-known manner. For improved security, the protected server shouldnot be the same processing system used in the manufacturing protectedsystem or the manufacturing production system. At block 704, the devicemanufacturer generates a key service public/private key pair that willbe used for the key retrieval service provided by the protected server.In one embodiment, the key service public/private key pair may be storedin the protected server. This key pair may be generated once for allprocessing performed by the system, or a new key pair may be generatedfor each class of devices. At block 706, the device manufacturerdelivers the key service public key 507 to the manufacturing protectedsystem 502.

FIG. 8 is a flow diagram 800 illustrating device manufacturing set-upprocessing according to an embodiment of the present invention. In oneembodiment, a device manufacturer may perform these actions using amanufacturing protected system 502. At block 802, the devicemanufacturer generates a Direct Proof Family key pair (Fpub and Fpri)for each class of devices to be manufactured. Each unique device willhave a DPpri key such that a signature created using DPpri may beverified by Fpub. A class of devices may comprise any set or subset ofdevices, such as a selected product line (i.e., type of device) orsubsets of a product line based on version number, or othercharacteristics of the devices. The Family key pair is for use by theclass of devices for which it was generated.

For each device to be manufactured, generation function 512 ofmanufacturing protected system 502 performs blocks 804 to 820. First, atblock 804, the generation function generates a unique pseudo-randomvalue (RAND) 508. In one embodiment, the length of RAND is 128 bits. Inother embodiments, other sizes of values may be used. In one embodiment,the pseudo-random values for a number of devices may be generated inadvance. At block 806, using a one-way function, f, supported by thedevice, the generation function generates a symmetric encryption keySKEY from the unique RAND value (SKEY=f(RAND)). The one-way function maybe any known algorithm appropriate for this purpose (e.g., SHA-1, MGF1,Data Encryption Standard (DES), Triple DES, Advanced Encryption Standard(AES), etc.). At block 808, in one embodiment, the generation functiongenerates an identifier (ID) label that will be used to reference thisdevice's keyblob 514 in the keyblob database 520 on the protected server522, by using SKEY to encrypt a “null entry” (e.g., a small number ofzero bytes) (Device ID=Encrypt (0 . . . 0) using SKEY. In otherembodiments, other ways of generating the Device ID may be used or othervalues may be encrypted by SKEY.

Next, at block 810, the generation function generates the DP privatesigning key DPpri correlating to the device's Family public key (Fpub).At block 812, the generation function hashes DPpri to produce DPpriDigest using known methods (e.g., using SHA-1 or another hashalgorithm). At block 814, the generation function builds a keyblob datastructure for the device. The keyblob includes at least DPpri and DPpriDigest. In one embodiment, the keyblob also includes a randominitialization vector having a plurality of pseudo-randomly generatedbits. These values may be encrypted using SKEY to produce an encryptedkeyblob 514. At block 816, the Device ID generated at block 808 and theencrypted keyblob 514 generated at block 814 may be stored in an entryin a keyblob database 520. In one embodiment, the entry in the keyblobdatabase may be indicated by the Device ID. At block 818, the currentRAND value may be stored in protected database 510. At block 820, SKEYand DPpri may be deleted, since they will be regenerated by the devicein the field.

The creation of the DPpri Digest and the subsequent encryption by SKEYare designed so that the contents of DPpri cannot be determined by anyentity that does not have possession of SKEY and so that the contents ofthe KeyBlob cannot be modified by an entity that does not havepossession of SKEY without subsequent detection by an entity that doeshave possession of SKEY. In other embodiments, other methods forproviding this secrecy and integrity protection could be used. In someembodiments, the integrity protection may not be required, and a methodthat provided only secrecy could be used. In this case, the value ofDPpri Digest would not be necessary.

At any time after block 820, at block 822 the protected database of RANDvalues may be securely uploaded to manufacturing production system 503that will store the RAND values into the devices during themanufacturing process. Once this upload has been verified, the RANDvalues could be securely deleted from the manufacturing protected system502. Finally, at block 824, the keyblob database 520 having a pluralityof encrypted keyblobs may be stored on the protected server 522, withone keyblob database entry to be used for each device, as indexed by theDevice ID field.

FIG. 9 is a flow diagram 900 illustrating device manufacturingproduction processing according to an embodiment of the presentinvention. As devices are being manufacturing in a production line, atblock 902 the manufacturing production system selects an unused RANDvalue from the protected database. The selected RAND value may then bestored into non-volatile storage in a device. In one embodiment, thenon-volatile storage comprises a TPM. In one embodiment, the RAND valuemay be stored in approximately 16 bytes of non-volatile storage. Atblock 904, a hash 509 of the key service public key 507 may be stored inthe non-volatile storage of the device. The hash may be generated usingany known hashing algorithm. In one embodiment, the hash value may bestored in approximately 20 bytes of non-volatile storage. At block 906,once the storage of the RAND value is successful, the manufacturingproduction system destroys any record of that device's RAND value in theprotected database 510. At this point, the sole copy of the RAND valueis stored in the device.

In an alternative embodiment, the RAND value could be created during themanufacturing of a device, and then sent to the manufacturing protectedsystem for the computation of a keyblob.

In another embodiment, the RAND value could be created on the device,and the device and the manufacturing protected system could engage in aprotocol to generate the DPpri key using a method that does not revealthe DPpri key outside of the device. Then the device could create theDevice ID, the SKEY, and the keyblob. The device would pass the DeviceID and the keyblob to the manufacturing system for storage in protecteddatabase 510. In this method, the manufacturing system ends up with thesame information (Device ID, keyblob) in the protected database, butdoes not know the values of RAND or of DPpri.

FIGS. 10-12 are flow diagrams of client computer system set-upprocessing according to an embodiment of the present invention. A clientcomputer system may perform these actions as part of booting up thesystem. Starting with flow 1000 on FIG. 10, at block 1002, the clientcomputer system may be booted up in the normal manner and a devicedriver software module 526 for the device may be loaded into main memoryof the client computer system. When the device driver is initialized andbegins execution, the device driver determines at block 1004 if there isalready an encrypted localized keyblob 524 stored in mass storage device308 for device 506. If there is, then no further set-up processing needbe performed and set-up processing ends at block 1006. If not, thenprocessing continues with block 1008. At block 1008, the device driverissues an Acquire Key command to the device 506 to initiate the device'sDP private key acquisition process.

At block 1010, the device driver sends the key service public key 507 tothe device. At block 1014, the device extracts the received key servicepublic key, generates a hash value of the key service public key, andcompares the hash of the received key service public key to the keyservice public key hash 509 stored in non-volatile storage on thedevice. If the hashes match, the received key service public key isknown to be that of the device manufacturer's key retrieval service, andclient computer system set-up processing continues.

In another embodiment, the device could receive a certificate of acertified key service public key for which the certificate could beverified through a certificate chain to the key service public key whosehash is the key service public key hash 509 stored in non-volatilestorage on the device. Then the certified key service public key couldbe used as the key service public key in the subsequent steps.

At block 1013 the device uses its one-way function f to regenerate thesymmetric key SKEY from the embedded RAND value 508 (SKEY=f(RAND)). Atblock 1020, the device then generates its unique Device ID label, byusing SKEY to encrypt a “null entry” (e.g., a small number of zerobytes) (Device ID=Encrypt (0 . . . 0) using SKEY). Processing continueswith flow diagram 1100 of FIG. 11.

At block 1102 of FIG. 11, the device generates a transient symmetric keyTkey. This key will be sent to the protected server, which may use thekey to encrypt the message the protected server returns to the device.At block 1104, the device builds a retrieve key request messagecontaining the Device ID and the transient symmetric key Tkey, encryptsthe message using the key service public key received from the devicedriver at block 1014, and sends the retrieve key request message to theprotected server via the device driver. (Retrieve Key Request=Encrypt(Device ID, Tkey) with the key service public key). One skilled in theart will recognize that to encrypt a message with a public key, onewould typically create a session key (Skey) for a symmetric cipher,encrypt the session key with the public key, and then encrypt themessage with the session key. At block 1106, the protected serverdecrypts the received key request message using the key service privatekey 511, and extracts the fields stored therein. Since the protectedserver now knows the Device ID (obtained from the key request message),the protected server searches the keyblob database for the recordcontaining the matching Device ID value, and extracts the device'sencrypted keyblob from the record. At block 1110, the protected serverbuilds a second response message containing the Family public key andthe encrypted keyblob and encrypts the second response message using thetransient symmetric key Tkey supplied by the device. Thus, KeyResponse=(Family public key, Encryption of (Encrypted Keyblob) usingTkey). Encrypting the Encrypted keyblob with Tkey is not to protect thekeyblob, since it is already encrypted with a symmetric key SKEY, whichonly the device can regenerate. Rather, encrypting the message in thisway ensures that the returned keyblob changes each time the keyacquisition process is performed, thus ensuring that the keyblob itselfcannot be used as a “cookie.” The second response message may bereturned to the device driver on the client computer system at block1112, which forwards the message to the device.

At block 1114, the device extracts the Family public key from the secondresponse message, decrypts the wrapped keyblob using the transientsymmetric key Tkey, and stores the encrypted keyblob in volatile memoryof the device. Processing then continues with flow diagram 1200 of FIG.12.

At block 1216 of FIG. 12, the device decrypts the encrypted keyblobusing the symmetric key SKEY, to yield DPpri and DPpri Digest, andstores these values in its non-volatile storage (DecryptedKeyblob=Decrypt (IV, DPpri, DPpri Digest) using SKEY). Theinitialization vector (IV) may be discarded. At block 1218, the devicethen checks the integrity of DPpri by hashing DPpri and comparing theresult against DPpri Digest. If the comparison is good, the deviceaccepts DPpri as its valid key. The device may in one embodiment alsoset a Key Acquired flag to true to indicate that the DP private key hasbeen successfully acquired. At block 1220, the device chooses a new IVand creates a new encrypted localized keyblob, using the new IV(Localized Keyblob=Encrypt (IV2, DPpri, DPpri Digest) using SKEY). Inone embodiment, the new encrypted localized keyblob may be returned to aKey Retrieval utility software module (not shown in FIG. 5) on theclient computer system. At block 1222, the Key Retrieval utility storesthe encrypted, localized keyblob in storage within the client computersystem (such as mass storage device 308, for example). The device'sDPpri is now securely stored in the client computer system.

Once the device has acquired DPpri during set-up processing, the devicemay then use DPpri. FIG. 13 is a flow diagram 1300 of client computersystem processing according to an embodiment of the present invention.The client computer system may perform these actions anytime afterset-up has been completed. At block 1302, the client computer system maybe booted up in the normal manner and a device driver 526 for the devicemay be loaded into main memory. When the device driver is initializedand begins execution, the device driver determines if there is alreadyan encrypted localized keyblob 524 stored in mass storage device 308 fordevice 506. If there is not, then the set-up processing of FIGS. 10-12is performed. If there is an encrypted localized keyblob available forthis device, then processing continues with block 1306. At block 1306,the device driver retrieves the encrypted localized keyblob andtransfers the keyblob to the device. In one embodiment, the transfer ofthe keyblob may be accomplished by executing a Load Keyblob command.

At block 1308 the device uses its one-way function f to regenerate thesymmetric key SKEY (now for use in decryption) from the embedded RANDvalue 508 (SKEY=f(RAND)). At block 1310, the device decrypts theencrypted localized keyblob using the symmetric key SKEY, to yield DPpriand DPpri Digest, and stores these values in its non-volatile storage(Decrypted Keyblob-Decrypt (IV2, DPpri, DPpri Digest) using SKEY). Thesecond initialization vector (IV2) may be discarded. At block 1312, thedevice checks the integrity of DPpri by hashing DPpri and comparing theresult against DPpri Digest. If the comparison is good (e.g., thedigests match), the device accepts DPpri as the valid key acquiredearlier, and enables it for use. The device may also set a Key Acquiredflag to true to indicate that the DP private key has been successfullyacquired. At block 1314, the device chooses yet another IV and creates anew encrypted localized keyblob, using the new IV (LocalizedKeyblob=Encrypt (IV3, DPpri, DPpri Digest) using SKEY). The newencrypted localized keyblob may be returned to the Key Retrievalutility. At block 1316, the Key Retrieval utility stores the encrypted,localized keyblob in storage within the client computer system (such asmass storage device 308, for example). The device's DPpri is nowsecurely stored once again in the client computer system.

In one embodiment of the present invention, it is not necessary togenerate all of the device DP private keys at one time. Assuming thatthe keyblob database on the protected server is updated regularly, thedevice DP private keys could be generated in batches as needed. Eachtime the keyblob database is updated on the protected server, it wouldcontain the keyblob database as generated to date, including thosedevice keys that had been generated but not yet assigned to devices.

In another embodiment, it may be possible to delay the generation of thedevice's DPpri key, allowing these keys to be generated only for thosedevices that require them. Upon receipt of the first key acquisitionrequest from the device, the protected sever may generate a request tothe manufacturing protected system, which still holds the device's RANDvalue. At this time, the manufacturing protected system generates theDPpri key for the device, returns it to the protected server, and onlythen destroys the RAND value.

In another embodiment, instead of storing the key service public keyhash in non-volatile storage on the device, the device manufacturer maychoose to store the hash of a root key, and then sign certificates forkey service public keys with the root key. In this way, the same rootkey could be used for a very large number of devices.

Although the operations discussed herein may be described as asequential process, some of the operations may in fact be performed inparallel or concurrently. In addition, in some embodiments the order ofthe operations may be rearranged without departing from the spirit ofthe invention.

The techniques described herein are not limited to any particularhardware or software configuration; they may find applicability in anycomputing or processing environment. The techniques may be implementedin hardware, software, or a combination of the two. The techniques maybe implemented in programs executing on programmable machines such asmobile or stationary computers, personal digital assistants, set topboxes, cellular telephones and pagers, and other electronic devices,that each include a processor, a storage medium readable by theprocessor (including volatile and non-volatile memory and/or storageelements), at least one input device, and one or more output devices.Program code is applied to the data entered using the input device toperform the functions described and to generate output information. Theoutput information may be applied to one or more output devices. One ofordinary skill in the art may appreciate that the invention can bepracticed with various computer system configurations, includingmultiprocessor systems, minicomputers, mainframe computers, and thelike. The invention can also be practiced in distributed computingenvironments where tasks may be performed by remote processing devicesthat are linked through a communications network.

Each program may be implemented in a high level procedural or objectoriented programming language to communicate with a processing system.However, programs may be implemented in assembly or machine language, ifdesired. In any case, the language may be compiled or interpreted.

Program instructions may be used to cause a general-purpose orspecial-purpose processing system that is programmed with theinstructions to perform the operations described herein. Alternatively,the operations may be performed by specific hardware components thatcontain hardwired logic for performing the operations, or by anycombination of programmed computer components and custom hardwarecomponents. The methods described herein may be provided as a computerprogram product that may include a machine readable medium having storedthereon instructions that may be used to program a processing system orother electronic device to perform the methods. The term “machinereadable medium” used herein shall include any medium that is capable ofstoring or encoding a sequence of instructions for execution by themachine and that cause the machine to perform any one of the methodsdescribed herein. The term “machine readable medium” shall accordinglyinclude, but not be limited to, solid-state memories, optical andmagnetic disks, and a carrier wave that encodes a data signal.Furthermore, it is common in the art to speak of software, in one formor another (e.g., program, procedure, process, application, module,logic, and so on) as taking an action or causing a result. Suchexpressions are merely a shorthand way of stating the execution of thesoftware by a processing system cause the processor to perform an actionof produce a result.

While this invention has been described with reference to illustrativeembodiments, this description is not intended to be construed in alimiting sense. Various modifications of the illustrative embodiments,as well as other embodiments of the invention, which are apparent topersons skilled in the art to which the invention pertains are deemed tolie within the spirit and scope of the invention.

What is claimed is:
 1. A method comprising: storing, in a memory of a processor-based device, a family public key for use by said device, as well as a group of other devices, said family public key paired with a family private key not stored on said device; and enabling a message signed with a direct proof private signing key, derived from said private signing key, to be verified by a member of said group using said family public key without revealing a member's identity.
 2. The method of claim 1 comprising: generating a key service public/private key pair for use in secure key retrieval processing by a client computer system and storing the key service public/private key pair in a protected on-line server; generating a pseudo-random value for a device; and storing the pseudo-random value and a hash value of the key service public key into non-volatile storage within the device during manufacture of the device, without storing the private key in the device.
 3. The method of claim 2 including: establishing a protected on-line server to support key retrieval requests from client computer systems to request a private key for a device of a class of devices present in a first client computer system, wherein the device does not include a private key and the first client computer system does not include an encrypted data structure associated with the device; generating the encrypted data structure associated with the device, the encrypted data structure comprising a private key; generating an identifier, based on the pseudo-random value, for the encrypted data structure; and storing the identifier and the encrypted data structure in a first database of the protected on-line server in an entry indicated by the identifier.
 4. The method of claim 3, further comprising: generating multiple encrypted data structures for multiple devices in the class of devices, the multiple encrypted data structures comprising multiple different private keys based at least in part on a Direct Proof family key pair for the class of devices, wherein a family public key of the Direct Proof family key pair can be used to verify that a signature created by any private key corresponding to at least one device in the class of devices without determining which specific device created the signature; generating multiple identifiers for the multiple encrypted data structures, based on pseudo-random values for the multiple devices; storing the multiple identifiers and the multiple encrypted data structures in the first database of the protected on-line server; storing a hash value of the key service public key into non-volatile storage in each of the multiple devices during manufacture of the devices; and storing a different one of the pseudo-random values into non-volatile storage in each of the multiple devices during manufacture of the devices.
 5. The method of claim 4, wherein: the private keys comprise Direct Proof private signing keys based at least in part on a family private key of the Direct Proof family key pair; and further comprising hashing the Direct Proof private signing keys to generate private key digests and including the private key digests in the encrypted data structures.
 6. The method of claim 3, further comprising generating a symmetric key based on the pseudo-random value for the device.
 7. The method of claim 6, wherein generating the identifier comprises encrypting a data value using the symmetric key.
 8. The method of claim 6, further comprising encrypting the data structure using the symmetric key.
 9. The method of claim 3, further comprising storing the key service public key on a manufacturing protected system.
 10. The method of claim 3, wherein the pseudo-random value for the device is unique.
 11. A non-transitory article storing instructions executed by a computer to perform the steps of: storing, in a memory of a processor-based device, a family public key for use by said device, as well as a group of other devices, said family public key paired with a family private key not stored on said device; and enabling a message signed with a direct proof private signing key, derived from said private signing key, to be verified by a member of said group using said family public key without revealing a member's identity.
 12. The article of claim 11 comprising: a storage medium having a plurality of machine readable instructions, wherein when the instructions are executed by a processor, the instructions provide for obtaining a private key for a trusted hardware device installed in a computer system by: determining if an encrypted data structure associated with the trusted hardware device installed in a computer system is stored in a memory on the computer system, wherein the encrypted data structure comprises a private key, a private key digest, and a first initialization vector for the trusted hardware device, the trusted hardware device of a class of devices and wherein the trusted hardware device does not include the encrypted data structure and includes a unique pseudo-random value stored in a non-volatile storage of the trusted hardware device.
 13. The article of claim 12 including: if the encrypted data structure is not stored in the memory, obtaining the encrypted data structure associated with the trusted hardware device from a protected on-line server accessible by the computer system, the server storing a database of encrypted data structures, each associated with a device of the class of devices; and processing the encrypted data structure and creating a localized encrypted data structure including the private key, the private key digest, and a second initialization vector, and storing the localized encrypted data structure in the memory.
 14. The article of claim 13, wherein instructions for obtaining the encrypted data structure comprise instructions for issuing an acquire key command to the trusted hardware device to initiate a private key acquisition process.
 15. The article of claim 13, wherein the private key comprises a Direct Proof private signing key based at least in part on a family private key of the Direct Proof family key pair for the class of devices.
 16. The article of claim 15, wherein instructions for the private key acquisition process comprise instructions for obtaining, by the trusted hardware device, a key service public key signed by a corresponding key service private key from the protected online server.
 17. The article of claim 16, wherein instructions for the private key acquisition process further comprise instructions for generating a symmetric key based on the unique pseudorandom value, and a device identifier, based on the pseudo-random value, for the encrypted data structure.
 18. The article of claim 17, wherein instructions for the private key acquisition process further comprise instructions for generating a transient symmetric key by the trusted hardware device, building a retrieve key message including the device identifier and the transient symmetric key, encrypting the retrieve key message using the key service public key, and sending the encrypted retrieve key message to the protected on-line server. 